1. The Field of the Invention
The present invention is directed generally to computers and file systems.
2. Background and Related Art
Typical file-systems provide mechanisms to manipulate a file-hierarchy, including the creation of new files or directories, the deletion or renaming of files or directories, and the manipulation of file contents. Certain file systems provide certain guarantees about the completion of a single low-level operation, i.e., primitive. For example, the primitive to create a new file will either complete successfully, or any partial effects of that create file operation will be undone by the system.
However, multiple file system operations at the user level may not be tied together within the file system. For example, there is presently no way for a file system to create four files, delete three others and rename another, but if any of these operations fail, undo any of the other operations. As a result, a higher-level (user level) process such as an application is employed to manage such multiple operations, i.e., to specify to the file system which actions are applied to which files and/or directories.
This solution has its own drawbacks, however. Consider an example wherein a web-site has twenty web pages linked to each other in a way that gives the site a consistent look and feel. During the updating of the site, the system may fail, causing an inconsistent state. For example, the application performing the update may have deleted some files but not the links from other files pointing to these files at the time of failure. A user viewing the site would see some of the web pages, but would receive error messages when clicking on the links to deleted pages.
To guard against the possibility of winding up in an inconsistent state, the entire web page file-hierarchy is ordinarily copied before any files in the hierarchy are changed. In the event of a failure, the saved hierarchy is copied back. However, this copying of the files is slow, relatively clumsy in that the copy program needs to know in advance what parts of the system are going to be updated, and error-prone, since if any file is inadvertently not copied, it is unrecoverable.
If the files are changed in place, when using a higher-level process to update files, any in-progress changes are visible to users viewing the site. For example, with the web-site described above, any changes are visible to the existing users of the system while the files (and the name hierarchy) are being changed by the application. Since the system-state state is typically inconsistent until all the changes have been made, users may see the inconsistency. For example, an existing user may see a link (URL) in a web-page, click on it and end up on a page that has been deleted—an event which happens when the application has deleted a page but not yet removed the link that pointed to the page.
In addition to web page updating, other programs are similarly limited in their ability to consistently save information. For example, a typical word processor application or a spreadsheet application performs full saves by rename and delete operations, using temporary files in order to avoid inconsistent states which may occur following system failures. Such applications also may want to distribute information across different data sources. For example, an application may desire to store tabular data in SQL Server, and files in a file server and/or in an Internet server, e.g., such files may include word processor documents, presentation charts, and/or web pages. However, no mechanism presently exists to support the saving of such information in a coordinated, unified manner. For example, if the system fails during the saving of such information, some of the pieces of information will be saved, but others will not, again leading to an inconsistent state.